Wide area network person-to-person payment

ABSTRACT

According to the invention, transferring money using a computer network is disclosed. In one step, information is saved on credit received for a first user ( 110 ) in a stored value account on a server computer system ( 170 ). At the server computer system ( 170 ), a request from the first user ( 110 ) to send money to a second user ( 130 ) based on the stored value account is received. An electronic notification is sent from the server computer ( 170 ) to the second user ( 130 ) to notify the second user ( 130 ) of the request. A debit in the stored value account of the first user ( 110 ) is created. The requested money is sent to the second user ( 130 ) upon a receipt of a request at the server computer ( 170 ) from the second user ( 130 ).

BACKGROUND

The invention relates generally to computer-implemented financialtransactions, and more particularly relates to processingperson-to-person payments and money requests using a computer network.

One individual (the payor) may wish to pay money to another individual(the payee) for any of a variety of reasons. Frequently, the payor owesa debt to the payee. The debt may be an informal IOU or a more formaltransaction. Other times, the payor may wish to give the money to thepayee as a gift.

Until now, individual payors have typically completed such payments viacash or paper check. More convenient payment methods exist, such ascredit cards and bank account debits through electronic fundtransactions, however, the payor typically does not have the option touse these other payment methods when the payee is an individual asopposed to a retail business that has been pre-established as an onlinemerchant. Thus, there is a need in the art for enabling individuals touse more convenient money transfer methods.

For individuals who participate in frequent money transfers to or fromother individuals, managing all these money transfers is alsoinconvenient. For example, a payor may receive requests for money frommultiple payees through different communication methods, including inperson, over the phone, and in writing. Keeping track of requests formoney is therefore time consuming. Likewise, the payee is often not sureof the best way to notify the payor of a money request. Accordingly,there is a need in the art for a convenient method by which a payee canrequest money from a payor.

Furthermore, a payor may desire to initiate a particular money transferat a future time. This may be the case with a birthday gift of money ora debt that is not due until a later date. If the payor attempts to waituntil the intended transfer date to give the payee a check or cash,however, the payor runs the risk that the payor will either forget ornot have the opportunity to give the check or cash to the payee. Thisproblem is particularly cumbersome when the payor must make recurringpayments of a fixed amount, such as for rent in an apartment. Therefore,there is also a need in the art for a mechanism for scheduling futurepayments that the payor does not want to initiate until a later time. Ingeneral, there is a need in the art for safe and convenient methods bywhich individuals can engage in money transfers.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described in conjunction with the appendedfigures:

FIG. 1A is a block diagram of an overview of person-to-person paymentsin accordance with an exemplary embodiment of the present invention;

FIG. 1B is a block diagram of an overview of person-to-person paymentsin accordance with another embodiment of the present invention;

FIG. 2 is a block diagram illustrating a log-in Web page for accessingan account with the payment enabler in accordance with an exemplaryembodiment of the present invention;

FIG. 3 is a block diagram illustrating an account history Web page inaccordance with an exemplary embodiment of the present invention;

FIG. 4 is a block diagram illustrating an address book interface inaccordance with an exemplary embodiment of the present invention;

FIG. 5 is a flow chart illustrating steps for registration of anindividual for an account with the payment enabler in accordance with anexemplary embodiment of the present invention;

FIG. 6 is a flow chart illustrating the steps of a process through whicha payor can send money in accordance with an exemplary embodiment of thepresent invention;

FIG. 7 is a flow chart illustrating the steps by which a payor canprovide transaction information to the payment enabler so that thepayment enabler can process a “send money” command in accordance with anexemplary embodiment of the present invention;

FIG. 8 is a flow chart illustrating the steps for completion of a “sendmoney” transaction by the payment enabler in accordance with anexemplary embodiment of the present invention;

FIG. 9 is a flow chart illustrating the steps of a process through whichan individual can request money from another person in accordance withan exemplary embodiment of the present invention; and

FIG. 10 is a flow chart illustrating the steps by which an individualcan provide information used by the payment enabler to process a moneyrequest in accordance with an exemplary embodiment of the presentinvention.

In the appended figures, similar components and/or features may have thesame reference label. Further, various components of the same type maybe distinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

DETAILED DESCRIPTION

The ensuing description provides preferred exemplary embodiment(s) only,and is not intended to limit the scope, applicability or configurationof the invention. Rather, the ensuing description of the preferredexemplary embodiment(s) will provide those skilled in the art with anenabling description for implementing a preferred exemplary embodimentof the invention. It being understood that various changes may be madein the function and arrangement of elements without departing from thespirit and scope of the invention as set forth in the appended claims.

The present invention processes person-to-person payment commands andmoney requests received from over a computer network such as theInternet. The payment enabler allows a remote individual to register foran account through which the individual can make payments to otherindividuals, request money from other individuals, and access otherfunctionality to facilitate the management of the individual's financialtransactions.

In addition to initiating immediate money transfer and request moneytransactions, an individual may use the payment enabler to schedulefuture or recurring transactions to one or more payees. Where there aremultiple payees, each payee may receive the same amount or a differingamount.

At the time an individual authorizes a payment to another person ordirects the payment enabler to request money from another person, theperson to whom the payment or money request is directed may, but neednot, have already registered for an account with the payment enabler.Where the payment is to an unregistered payee, the payment may be in theform of a gift certificate, an electronic gift certificate, a moneyorder, a check, a savings bond, an airline mileage credit, or negotiableinstrument sent to the payee who would never need to register in orderto receive the payment. When communicating with individuals, the paymentenabler may use both mail, telegrams, telephone, pages, instantmessaging, Web pages and/or e-mail.

An intermediary typically operates the payment enabler and acts as aconduit for the money transfer from one individual (the payor) toanother individual (the payee). This enables the payor to pay through avariety of different payment methods and the payee to receive paymentthrough a variety of different methods. Individuals, by way of theintermediary, may make payments from and receive money transfers into astored value account.

Address book functionality provides users the ability to retaininformation on counter parties. The address book may be integrated intothe money transfer and money request interfaces to allow an individualto quickly select the counter party for a transaction. The individualsin the address book may be manually entered or automatically entered asa previous counter party.

Generally described, the present invention comprises a method forproviding a person-to-person payment service through a computer serverof a computer network. The computer server maintains a database ofe-mail addresses corresponding to individuals having accounts thatprovide the individuals with functionality offered by the computerserver for online management of financial transactions. The computerserver receives from a first individual located at a remote computer ane-mail address of a second individual to whom the first individual wantsto send an amount of money. Then, the computer server searches thedatabase of e-mail addresses for the e-mail address of the secondindividual. If the e-mail address of the second individual is found inthe database of e-mail addresses, then the payment of the amount ofmoney from the first individual to the second individual is completed.

To complete the payment of the amount of money from the first individualto the second individual, the computer server may first initiate atransfer of the amount of money from the first individual to a firstintermediary bank account using a first money transfer method. Thecomputer server then transfers the amount of money from a secondintermediary bank account to the second individual using a second moneytransfer method.

The present invention also comprises a method for providing a moneyrequest service through a computer server of a computer network. Thecomputer server maintains a database of e-mail addresses or other uniqueidentifier corresponding to individuals having accounts that provide theindividuals with functionality offered by the computer server for onlinemanagement of financial transactions. The computer server then receivesfrom a first individual located at a remote computer an e-mail addressof a second individual from whom the first individual wants to requestan amount of money. The computer server sends an email to the e-mailaddress of the second individual to notify the second individual thatthe first individual is requesting the amount of money. The computerserver then receives authorization from the second individual to pay theamount of money to the first individual. The computer server nextcompletes a payment of the amount of money from the second individual tothe first individual.

The present invention is typically embodied in a server, called apayment enabler, that processes person-to-person payment commands andmoney requests received from over a computer network such as theInternet. The payment enabler allows an individual to register for anaccount through which the individual can make payments to otherindividuals, request money from other individuals, and access otherfunctionality to facilitate the management of the individual's financialtransactions. The payment enabler may, for example, provide the user ofan account with access to online statements listing the user's pendingand history (past) transactions.

To communicate with individuals, the payment enabler may use both Webpages and e-mail. Web pages may allow the payment enabler to bothcommunicate information to and receive information from an individual.E-mail provides a convenient mechanism through which the payment enablercan reach individuals who have not registered with the payment enablerand update individuals about the status of a particular transaction.

At the time an individual authorizes a payment to another person ordirects the payment enabler to request money from another person, theperson to whom the payment or money request is directed may, but neednot, have already registered for an account with the payment enabler. Ifthe person to whom the payment or money request is directed does notalready have an account with the payment enabler, then the paymentenabler e-mails that person to invite his or her registration for anaccount so that the transaction can be completed.

An intermediary typically operates the payment enabler and acts as aconduit for the money transfer from one individual (the payor) toanother individual (the payee). This enables the payor to pay through avariety of different payment methods and the payee to receive paymentthrough a variety of different money receipt methods.

For example, individuals may make payments from and receive moneytransfers into a stored value account, also called a virtual privatepayment account. The stored value account holds payment credit that isdeducted as portions of that credit is transferred to payees. Where thepayee also has an account with the payment enabler, payment passes fromthe payor's stored value account to the payee's stored value account.The individual may have a physical card associated with the stored valueaccount. Using the card, the individual may make payments tobrick-and-mortar stores by drawing upon funds in the stored valueaccount.

Some embodiments may automatically sweep credits from a stored valueaccount out to the individual associated with the stored value account.Credits may accumulated in an individual's stored value account overtime. Periods or thresholds can be configured that automatically cause atransfer of credits out of the stored value account. For example, everymonth the credits could be swept into a banking account or when thecredit balance exceeds $1000 a money order could be mailed to theindividual.

In addition to initiating immediate money transfer and request moneytransactions, an individual may use the payment enabler to schedule afuture or recurring payment or money request to another individual. Anindividual may schedule the dates for a future or recurring transactionvia selection from a pull-down menu, typing in the dates, selectingdates by clicking on them in a graphical calendar interface, and thelike. For a recurring transaction, the individual may use any of theabove methods to specify a date to make the initial payment or moneyrequest and then specify a frequency and duration for repeating thepayment or request.

Address book functionality may provide users the ability to retaininformation on counter parties. The address book may be integrated intothe money transfer and money request interfaces to allow an individualto select quickly the counter party for a transaction.

Under some circumstances, the payee of a transaction may receive acustomary greeting card as part of the same transaction. An electronicgreeting card would include a link to the payment enabler that wouldallow receiving a payment from the donor/payor. The payment could be inthe form of a gift certificate that is redeemable at one or moreInternet or bricks-n-mortar retailers. Some embodiments, could allowon-line selection of a greeting card that is printed and sent along witha money order, gift certificate, check, or negotiable instrument.

Although the present invention has thus far been described in thecontext of transactions between individuals, one skilled in the artshould appreciate that the methods described in the detailed descriptioncan also apply to transactions where one or both of the parties isanother type of entity, such a business, merchant, corporation, group,or the like. Moreover, an individual may command the payment enabler tomake a payment to several different individuals in a single transaction.Likewise, an individual may instruct the payment enabler to requestmoney on the individual's behalf from several other people in a singletransaction.

Person-to-Person Payment Overview

FIG. 1A provides an overview 100 of person-to-person payments accordingto an exemplary embodiment of the present invention. The overview 100illustrates a payor 110 who needs to transfer an amount of money (alsocalled a payment) 180 to a payee 130.

The payment enabler 170 is typically hosted by a server linked to acomputer network such as the Internet 150. Accordingly, the paymentenabler 170 is accessible over the Internet 150 by individuals (e.g.,the payor 110 and the payee 130) located at computers (e.g., thecomputers 120 and 140) that are remote from the payment enabler 170. Thepayment enabler 170 enables these individuals 110, 130 to register foran account with which they can make payments to other individuals,request money from other individuals, and access other functionality tofacilitate the management of the individuals' financial transactions.

The payor 110 typically accesses the Internet 150 through the payorcomputer 120, and the payee 130 typically accesses the Internet 150through the payee computer 140. The payor computer 120 and the payeecomputer 140 may be linked to the Internet 150 in the customary manner.To enable the payor 110 and the payee 130 to access the functionality ofthe various servers connected to the Internet 150, the payor computer120 and the payee computer 140 typically run a Web browser that enablestheir users to communicate with these various servers through Web pages.The payor 110 and the payee 130 may also access the payment enabler 170in this manner. Other computer users (not shown) may access the Internet150 and the payment enabler 170 in a similar manner.

Using the payment enabler 170, the payor 110 may complete a moneytransfer of a payment 180 to the payee 130. In such a transaction, anintermediary 160 may act as a conduit for the money transfer of theamount 180. Typically, the intermediary 160 is a business that operatesthe payment enabler 170. By acting as a conduit for a money transferbetween the payor 110 and the payee 130, the intermediary 160 enablesthe payor to pay through a variety of different payment methods and thepayee to receive payment through a variety of different money receiptmethods. As shown in the overview 100, the intermediary 160 collects thepayment 180 from the payor 10—via a first money transfer method, and theintermediary transfers the payment to the payee 130 via a second moneytransfer method.

Typically, the intermediary 160 receives the transfer of money 180 viathe first money transfer method into a first bank account. Theintermediary 160 typically transfers money 180 from a second bankaccount to the payee 130 via the second money transfer method. The firstbank account and the second bank account may, but need not, be the sameaccount.

Although the intermediary 160 may receive the payment 180 from the payor110 before the intermediary transfers the payment to the payee 130, theintermediary may choose to pay the payee before receiving payment fromthe payor. In this case, the intermediary 160 assumes the risk ofnonpayment by the payor 110. Instead of assuming the risk of nonpaymentin order to pay the payee 130 before receiving payment 180 from thepayor 110, the intermediary 160 may pay a third party (not shown) toassume the risk of nonpayment by the payor.

Those skilled in the art will be familiar with a variety of moneytransfer methods. The first money transfer method from the payor 110 tothe intermediary 160 may comprise such payment methods as receiving adeposit of an amount of cash by the payor at the store of a paymentprocessor that transfers the amount to the intermediary, debiting acredit card of the payor, debiting a bank account of the payor in anelectronic find transaction, debiting a stored value account (alsocalled a virtual private payment account) of the payor, receiving apaper check from the payor, and the like. The second money transfermethod from the intermediary 160 to the payee 130 may comprise suchmoney receipt methods as debiting a bank account of the intermediary tofund the dispensing of cash to the payee through an automated tellermachine (ATM), dispensing cash to the payee at a store of a paymentprocessor that funds the transaction by debiting a bank account of theintermediary, crediting a credit card of the payee, crediting a bankaccount of the payee in an electronic fund transaction, crediting astored value account of the payee, sending a paper check to the payee,and the like.

By way of further explanation, a stored value account may have a balancethat can be credited and debited. A business managing the stored valueaccount typically guarantees the account owner the ability to convertthe account balance to cash or cash-equivalents through withdrawals orpayments to other entities made against the account balance. For theaccount owner to make a payment to an entity or individual against thebalance in a stored value account, that entity typically arranges toaccept payment from the business managing the stored value account priorto the transaction. When the business managing the stored value accountreceives money on the behalf of the account owner, the balance of theaccount owner's stored value account is credited. In some embodiments,the business managing the stored value account is the same businessrunning the payment enabler.

The transfer of money 180 via the first money transfer method and/or thesecond money transfer method may be executed using money transferprocessing systems (not shown) that are managed by the intermediary 160.Alternatively, either or both of these transfers may be executed usingmoney transfer processing systems (not shown) of third parties. Todirect a money transfer processing system to perform a money transferand provide it with the appropriate transaction details, the paymentenabler 170 may communicate with the processing system over the Internet150, over dedicated network connections, or through other means. Thedetails of money transfer processing systems for various payment methodsand money receipt methods are well known to those skilled in the art.

With reference to FIG. 1B, a block diagram of a system 105 forperson-to-person payments in accordance with another embodiment of thepresent invention is shown. In this embodiment, both the payor and payee110, 130 have respective stored value accounts 190.

Although only one intermediary 190-1 is shown in FIG. 1B for the payor110, the payor 110 configures any number of intermediaries 160 to sendpayment credits to and/or receive payment credits from the payor'sstored value account 190-1. The stored value account 190-1 may bereceive credits from other individuals or from any of the intermediaries160 at the request of the payor or as credits are needed.

When a transaction is initiated, the payor's stored value account 190-1receives credits from a selected first intermediary 160 under thedirection of the payment enabler 170 such that sufficient credits arepresent to fund the transaction. The payment 180 passes from the payor'sstored value account 190-1 to the payee's stored value account 190-2 ascontrolled by the payment enabler 170. The payee 130 is notified withe-mail, for example, of the new credit to the stored value account190-2. With the assistance of a second intermediary 160-2 underdirection from the payment enabler 170, the credit can be withdrawn bythe payee 130. Although only one second intermediary 160-2 is shown, anynumber of intermediaries may be possible to transfer all or part of thecredit from the stored value account 190-2 of the payee.

The above embodiment credits the payor's 110 stored value account 190-1before transferring the credit to the payee's 130 stored value account190-2. Other embodiments could avoid the payor's 110 stored valueaccount 190-1 and directly transfer the credit from the firstintermediary 160-1 to the payee's 130 stored value account 190-2. Forexample, the first intermediary 160-1 may be a credit card company thatadds money to the stored value account 190-2 of the payee 130. In otherembodiments, money may go from the payor's stored value account 190-1directly to the second intermediary 160-2. For example, a credit in thestored value account 190-1 of the payor 110 could be sent to a secondintermediary 160-2 that issues money orders for pick-up by the payee ata retail location.

Hardware and Software for Implementing Person-to-Person Payments

The payor computer 120, the payee computer 140, and the server hostingthe payment enabler 170 may each have typical features of a computersystem, such as a processing unit, a system memory containing randomaccess memory (RAM) and read only memory (ROM), and a system bus thatcouples the system memory to the processing unit. The computer may alsoinclude various memory storage devices, such as a hard disk drive, amagnetic disk drive (e.g., to read from or write to a removable magneticdisk), and an optical disk drive (e.g., to read from or write to opticalmedia such as a CD-ROM). The payor computer 120 and the payee computer140 may also comprise devices capable of wireless access to the Internet150. Further, the payment enabler 170 may be implemented with a numberof such computers interconnected by a network as is well known in theart.

A number of program modules may be stored in the drives and RAM of thecomputer system. Program modules control how the computer systemfunctions and interacts with the user, with input/output devices, orwith other computers. Program modules include routines, an operatingsystem, application program modules, data structures, browsers, andother software or firmware components. The invention may conveniently beimplemented in various program modules that are stored on the computersillustrated in the overview 100 and implement the methods described inthe detailed description.

No particular programming language will be described for carrying outthe various procedures described in the detailed description because itis considered that the operations, steps, and procedures described andillustrated in the accompanying drawings are sufficiently disclosed topermit one of ordinary skill in the art to practice an exemplaryembodiment of the present invention. Moreover, there are many computersand operating systems which may be used in practicing an exemplaryembodiment, and therefore no detailed computer program could be providedwhich would be applicable to all of these many different systems. Eachuser of a particular computer will be aware of the language and toolswhich are most useful for that user's needs and purposes.

One skilled in the art should recognize that the various computers 120,140, 170 may require one or more databases for storing informationpertinent to their roles in the person-to-person payment methods of thepresent invention. In the detailed description, these databases may bedescribed with respect to their functionality or the information stored.One skilled in the art should recognize that a variety of differentdatabase implementations are capable of providing the describedfunctionality or storing the described information. Accordingly, detailsof such database implementations need not be described. Where details ofa database implementation are described, the detailed descriptionprovides them by way of example, not by way of limitation.

Accessing the Functionality of the Payment Enabler

FIG. 2 is a screen shot illustrating an exemplary login Web page 200through which a user of the payment enabler 170 can access his or heraccount. This account enables the user to access the features of thepayment enabler. If the user makes a payment 180 to another individualusing the payment enabler 170, then the user is referred as the payor110 with respect to that particular transaction. If the user receives apayment from another individual through the payment enabler 170, thenthat user is referred to as a payee 130 with respect to that particulartransaction. Through the account, the user also has access to otherfunctionality of the payment enabler 170 for facilitating the managementof that user's financial transactions.

As already described, the payment enabler 170 may require the user toundergo a registration process before activating an account for theuser. As a result of that registration process, the user may be assigneda user name and a password. To access his or her account, the userenters the assigned user name in box 205 and the password in box 210.When the user next clicks the “LOGIN” button 215, the payment enabler170 determines if the password on file for the account associated withthe user name supplied by the user matches the password supplied by theuser. If so, then the payment enabler 170 grants the user access to theaccount associated with the user name supplied by the user.

The leftmost side of the login Web page 200 may have several buttons225, 230, 240, 250, 260, 270, 280, 290, each labeled and associated witha particular feature of the payment enabler 170. By selecting aparticular button, perhaps with a pointing device such as a mouse, theuser can access the feature of the payment enabler associated with thatbutton. These buttons 225, 230, 240, 250, 260, 270, 280, 290 aretypically inactive until the user has been granted access to the user'saccount through the login process.

The features associated with each of the buttons 225, 230, 240, 250,260, 270, 280, 290 are now discussed in turn. In response to the userclicking the button 225, the payment enabler 170 may provide the userwith a Web page alerting the user to new money requests received andpayments completed since this button was previously selected. Inresponse to the user clicking the button 230, the payment enabler 170initiates the “send money” process 600 (described in more detail laterin conjunction with the description of FIGS. 6-8), which allows the user(the payor 110 with respect to this transaction) to send money toanother individual, the payee 130. In response to the user clicking thebutton 240, the payment enabler 170 initiates the “request money”process 900 (described in more detail later in conjunction with thedescription of FIGS. 9 and 10), which allows the user (the payee 130with respect to this transaction) to request money from anotherindividual, the payor 110.

In response to the user clicking the button 250, the payment enabler 170provides the user with an online statement of pending “send money” or“request money” transactions. In response to the user clicking thebutton 260, the payment enabler 170 provides the user with an onlinestatement of history (i.e., past or completed) “send money” or “requestmoney” transactions. Such an online statement of completed transactionsis further described in more detail later in conjunction with thedescription of FIG. 3.

In response to the user clicking the button 270, the payment enabler 170provides the user with an address book interface 400 (described in moredetail later in conjunction with the description of FIG. 4). Thisaddress book interface 400 provides the user with extensive address bookfunctionality.

In response to the user clicking the button 280, the payment enabler 170provides the user with a Web page having a summary of the user's profile(i.e., registration information). Through this Web page, the user may beable to update his or her profile. Updating profile information mayinclude adding or deleting money transfer methods for either makingpayments or receiving payments. The user may also change the defaultpayment or money receipt method for the user's account through thisfeature.

In response to the user clicking the button 290, the payment enabler 170may provide the user with an online calendar through which the user cankeep track of various events, including but not limited to financialtransactions. Such online calendars are well known to those skilled inthe art. The calendar may automatically indicate future and recurringtransactions that have been scheduled. Such scheduled transactions mayinclude automatic initiation of a payment or sending of a money request.By clicking on a transaction listed on the online calendar, the user canchange the details (including scheduling) of the transaction.

The above embodiment allows sending payment 180 to a single payee 130,however, other embodiments could send payment to a number of payees. Thepayor may enter a list of e-mail addresses for the payees manually, loadthat list from a file or select existing entries from the address book.The address book may include a group of individuals. The group can beselected as the payees. Further, each individual in the group couldreceive the same or a different amount of payment 180 in their storedvalue account.

When a particular button 225, 230, 240, 250, 260, 270, 280, 290 isselected, the payment enabler 170 typically highlights it and providesthe selected functionality in the large area 220 of the graphical userinterface. The buttons 225, 230, 240, 250, 260, 270, 280, 290 may bedisplayed on all Web pages provided to the user by the payment enabler170 in order to provide the user with an easy way to switch betweenfeatures of the payment enabler while logged into his or her account.

Online Statements of Pending and Completed Transactions

FIG. 3 is a screen shot illustrating an exemplary account history Webpage 300, which the user may access by selecting the “View History”button 260. The online statement of history transactions is displayed inthe area 220 of the Web page. Because the button 260 has been selected,it is shown highlighted. The other buttons 225, 230, 240, 250, 270, 280,290 are provided toward the leftmost side of the Web page to allow theuser to easily switch to other features of the payment enabler 170. Asthose skilled in the art appreciate, there may be levels of menus withadditional buttons to access some of the other functions.

The online statement of history transactions comprises completedtransactions 310. A given transaction may comprise a “send money”transaction or a “request money” transaction depending on whether theuser wishes to send money to another individual or requested money fromanother individual. Each of the transactions 310 occupies one row of thearea 220 and includes entries for each of the columns 320, 330, 340,350, 360, 370, 380, 390. By clicking on a column head, the user can sortthe transactions 310 by their entries for the column corresponding tothat column head.

For each of the transactions 310, the entry in column 320 comprises thename of the counter party to the transaction. The entry in column 330comprises a unique reference number assigned to the transaction by thepayment enabler 170. The entry in column 340 comprises the e-mailaddress of the counter party to the transaction. The entry in column 350comprises the amount 180 that the user sent to or requested from thelisted counter party for the transaction. The entry in column 360comprises the date that the transaction was initiated. The entry incolumn 370 comprises a subject that the user has provided to identifythe transaction.

The entry in column 380 indicates the type of the transaction. Forexample, the word “send” in this column 380 may indicate a “send money”transaction. “Request” may indicate a “request money” transaction.“Receive” may indicate a transaction in which money was received fromanother individual who used the “send money” process 600.

In some embodiments of the present invention, a payee 130 in a giventransaction has the opportunity to reverse a received payment. In thatcase, the type column 380 for that transaction may have the word“refund.”

The entry in column 390 indicates the status of the transaction. If thetransaction has been completed, then the word “fulfilled” may appear inthe column 390. In some embodiments of the present invention, a payor110 in a given transaction has the opportunity to cancel a pendingtransaction before it is completed. The word “canceled” in the column390 may indicate such a canceled transaction.

By clicking the button 250, the user of an account can obtain a Web page(not shown) similar to that of FIG. 3 but listing only pendingtransactions. Pending transactions include transactions that the userauthorized the payment enabler 170 to initiate but that have not yetbeen completed. Such transactions may be indicated by the word “pending”in the status field 390.

In some embodiments of the present invention, the payment enabler 170permits a user who has begun entering transaction details but has notfinished to save the details entered up till that point. In such anembodiment, the user can later complete entry of the transaction detailsand then authorize the payment enabler 170 to initiate the transaction.Such a transaction may be listed in the statement of pendingtransactions with the word “draft” in the status field.

Address Book Functionality

FIG. 4 is a screen shot illustrating an exemplary address book interface400. The user may access this address book interface 400 by clicking onthe button 270.

The address book interface includes a listing of address book entries410 for a user-defined group of people. Each address book entry occupiesa row of the display and includes information for each of the columns420, 425, 430. By clicking on a column head for one of these columns,the user can sort the address book entries 410 by their information inthe column corresponding to that column head. Column 415 comprises acheck box that can be either checked or unchecked for each of theaddress book entries 410.

For each of the address book entries 410, the information in column 420comprises the name of a person with an e-mail address. The informationin column 425 comprises an e-mail address of the person listed in column420. The information in column 430 comprises the number of transactionscurrently pending for the user with the person listed in column 420 asthe counter party.

By clicking the button 460, the user can add a new address book entry tothe current display of address book entries. There may also be a button(not shown) allowing the user to delete an address book entry from thecurrent display of address book entries.

By clicking the button 470, the user can save the entries 410 in thecurrent display of address book entries for future reference. After theuser clicks the button 470, a subsequent Web page may prompt the userfor the name under which the group should be saved. If the group beingsaved is an update to a group that was earlier saved, the Web page mayprovide the user the option to replace the old group by saving theupdated group under the same name as the old group was saved.

By clicking the drop-down menu 480, the user can select a previouslysaved group. In response, the payment enabler provides the user with aWeb page like that of FIG. 4, except the address book entries 410 of thecurrent group are replaced with address book entries for the selectedgroup.

By making a selection from the drop-down menu 490, the user can importaddress book entries from other programs. Once imported, these addressbook entries will be displayed on a Web page similar to that of FIG. 4as the address book entries 410.

By clicking on the button 440, the user initiates the “send money”process 600 (discussed later) to send money to all the individuals whoseaddress book entries 410 are checked in column 415. By clicking on thebutton 450, the user initiates the “request money” process 900(discussed later) to request money from all the individuals whoseaddress book entries 410 are checked in column 415. When the “sendmoney” process 600 and the “request money” process 900 are initiated inthis manner through the address book interface 400, the user need notlater specify again the individuals (and their e-mail addresses) to whomthe User wishes to pay money or from whom the user wishes to requestmoney.

The user may check the check box (column 415) for one or more of theaddress book entries 410 by clicking on that check box. The user mayuncheck an already checked check box by clicking on it again.

Registration for an Account with the Payment Enabler

FIG. 5 is a logical flow diagram 500 illustrating exemplary steps forregistration of an individual for an account with the payment enabler170. The registration process begins with step 510. For transactionsthat send payment to one or more groups of individuals, a listing of allgroups is shown in a manner similar to that of FIG. 4. A set payment maybe configured for the whole group or different payment amounts 180and/or different payment methods may be selected for each individual.

In step 510, the individual establishes a secure connection with thepayment enabler 170. Typically, the individual communicates with thepayment enabler 170 via Web pages. In step 520, the individual providesthe payment enabler 170 with the individual's e-mail address and otheridentification information included in the individual's profile.

In step 530, the individual provides the payment enabler 170 withinformation for one or more payment methods. In step 540, the individualselects a default payment method.

In step 550, the individual provides the payment enabler 170 withinformation for one or more methods of receiving money. In step 560, theindividual selects a default method for receiving money.

In step 565, the payment enabler 170 provides the individual with a username and password. Alternatively, the payment enabler 170 may permit theindividual to choose his or her own password. In some embodiments, thee-mail address serves as the user name.

In step 570, the payment enabler 170 creates a database record thatstores the individual's account information. This account informationincludes the profile of the individual, as well as the individual's username and password. This database record may also include a pendingtransactions file and a history transactions file that store theinformation that the payment enabler 170 respectively uses to produce atthe individual's request the online statement of pending transactionsfor the individual and the online statement of history transactions forthe individual.

In step 580, the payment enabler 170 sends the individual a confirmatione-mail having a deep link that the individual can follow to activate theaccount. In step 590, the individual follows the deep link to activatethe account. The registration process then ends in step 595. Once theaccount is activated, a stored value account 190 is created that islinked to the individual.

Sending Money to Other Individuals

FIG. 6 is a logical flow diagram 600 illustrating exemplary steps for asend money process 600 in which a payor 110 can send money 180 to apayee 130. The send money process 600 begins with step 610.

In step 610, the payor 110 logs into the payor's account through asecure connection with the payment enabler 170 and selects the “sendmoney” option, perhaps by clicking the “send money” button 230.

In step 620, the payor 110 provides the payment enabler 170 with thesend money transaction information. The payor 110 may communicate thisinformation to the payment enabler 170 through Web forms.

In step 630, the payment enabler 170 searches for the e-mail address ofthe payee 130 in the database of user accounts to determine if the payeeis a registered user. In step 635, the payment enabler 170 determines ifthe e-mail address of the payee 130 was found. If the e-mail address ofthe payee 130 was found, then the “YES” branch is followed to step 690because the payee is already a registered user. In that case, thepayment enabler 170 completes the transaction in step 690 before thesend money process 600 ends in step 695.

Referring again to step 635, if the payment enabler 170 determines thatthe e-mail address of the payee 130 was not found, then the “NO” branchis followed to step 640 because the payee is not already a registereduser. In step 640, the payor 110 specifies a question and an expectedanswer for the purpose of authenticating the payee 130. Although thisembodiment uses a secret question for authentication, other embodimentscould use encryption, a certificate, a biometric device or othertechnology for authorization.

In step 650, the payment enabler 170 sends the payee 130 an e-mail tonotify the payee that the payee can receive the payment from the payor110 by registering for an account with the payment enabler. The e-mailmay include a link that the payee 130 can follow to register for theaccount with the payment enabler 170. In step 660, the payment enabler170 determines if the payee registers for an account with the paymentenabler.

If the payee 130 never registers for an account with the payment enabler170, then the “NO” branch is followed to step 695, and the send moneyprocess 600 ends. If, in step 660, the payee 130 does register for anaccount with the payment enabler 170, then the “YES” branch is followedto step 670.

In step 670, the payment enabler 170 poses the security question to thepayee 130 and receives a response from the payee. In step 680, thepayment enabler 170 determines if the response matches the expectedanswer to the security question that was entered by the payor 110 instep 640. If the response does not match the expected answer, then the“NO” branch is followed to step 695, and the send money process 600ends.

If the response does match the expected answer in step 680, then the“YES” branch is followed to step 690. In step 690, the payment enabler170 completes the transaction. The send money process 600 then ends instep 695.

In the above embodiment, the payee 130 interacts with the paymentenabler 170 in order to transfer payment 180 to a stored value account160-2 for the payee. Other embodiments could send the payment 180directly to the payee without the need for interaction with the paymentenabler 170, by sending a check or other instrument directly to thepayee 130. Further, the payee may merely be informed of the payment 180and pick-up the payment from an intermediary 160 with a retailstorefront.

FIG. 7 is a logical flow diagram 620 illustrating exemplary steps forprovision of the “send money” transaction information to the paymentenabler 170 by the payor 110. The logical flow diagram of FIG. 7comprises an exemplary process corresponding to routine 620 on FIG. 6.The routine 620 begins with step 710.

In step 710, the payor 110 specifies the e-mail address of the payee130. The payor 110 may do this by typing in the e-mail address or byselecting the e-mail address from an online e-mail address book. Otherembodiments could use any unique identifier and not just an e-mailaddress.

In step 720, the payor 110 specifies the amount 180 to pay the payee130. In step 730, the payor 110 may specify a subject that may identifythe transaction in the pending and history transactions files. Thesubject may also identify the transaction in the subject line of ane-mail to the payee 130 about the transaction. If an auction payment,the subject may include an auction identifier such as an auction listingtitle and/or an auction number. In step 740, the payor 110 optionallyspecifies a message for the payment enabler 170 to include in the e-mailnotifying the payee 130 of the transaction.

In step 750, the payor 110 optionally selects a payment method to beused in this transaction instead of the default payment method. In step760, the payor 110 optionally identifies the payment 180 as a future ora recurring payment. The payment enabler 170 may provide a graphicalcalendar to assist in scheduling future payments. For example, the payor110 may click a box corresponding to a specific day to schedule thepayment 180 for that day. In some embodiments, the payor 110 mayindicate payment should be a check, money order, gift certificate, orother instrument. The instrument could be mailed directly to a payeeaddress provided by the payor 110 or picked-up by the payee 130 at alocal storefront.

In step 770, the payment enabler 170 displays a summary of thetransaction to the payor 110. In step 780, the payment enabler 170offers the payor 110 the opportunity to confirm the transaction or toreenter the transaction information. In step 790, the payment enabler170 determines if the payor 110 has confirmed the transaction. If thetransaction is confirmed, then the “YES” branch is followed to step 795,and the routine 620 returns. However, if the payment enabler 170determines in step 790 that the payor 110 has decided not to confirm thetransaction, then the “SNO” branch is followed back to step 710, and thepayor reenters the transaction information.

FIG. 8 is a logical flow diagram 690 illustrating exemplary steps forcompletion of the “send money” transaction by the payment enabler 170.The logical flow diagram of FIG. 8 comprises an exemplary processcorresponding to routine 690 of FIG. 6. The routine 690 begins with step810.

In step 810, the payment enabler 170 assigns a unique transactionidentifier to the transaction and creates a database record of thetransaction. This unique identifier may be used to access the record ofa transaction whenever a customer inquires about the transaction.

In step 820, the payment enabler 170 initiates the transfer of thepayment amount 180 from the payor 110 to the intermediary 160 using thefirst money transfer method. Some embodiments may move the payment fromthe payor's stored value account 190-1 to the payee's stored valueaccount 190-2 to accomplish the transfer. If the payor 110 identifiedthe payment 180 as a future or recurring payment in step 760 of FIG. 7,then the payment enabler 170 waits until the specified time or times toinitiate the transfer of the payment amount 180 from the payor to theintermediary 160.

If the payor 110 specified a particular payment method to be used inthis transaction in step 750 of FIG. 7, then that payment methodcomprises the first money transfer method. Otherwise, the first moneytransfer method comprises the default payment method specified for theaccount of the payor 110.

In step 830, the payment enabler 170 updates the pending transactionsfile for the payor 110. Typically, this update involves adding thetransaction to the pending transactions file for the payor 110 as a“send” type transaction with a “pending” status.

In step 840, the payment enabler 170 updates the pending transactionsfile for the payee 130. Typically, this update involves adding thetransaction to the pending transactions file for the payee 130 as a“receive” type transaction with a “pending” status.

In step 850, the intermediary 160 receives the payment amount 180. Instep 860, the payment enabler 170 transfers the payment amount 180 fromthe intermediary 160 to the payee 130 using the second money transfermethod. Typically, the second money transfer method comprises thedefault money receipt method specified for the account of the payee 130.

The payment enabler 170 may send an e-mail to the payee 130 to notifythe payee of the money 180 being sent. This e-mail may optionallyrequire that the payee 130 authorize receipt of the money 180 before thepayment enabler 170 will complete the payment through the second moneytransfer method. This e-mail may also optionally offer the payee 130 theopportunity to change the second money transfer method for thisparticular transaction from the default money receipt method to anothermoney receipt method.

In step 870, the payment enabler 17.0 changes the status of thetransaction for both the payor 110 and the payee 130 from “pending” to“fullfilled” and moves the transactions from their pending transactionsfiles to their history transactions files.

In step 880, the payment enabler 170 may send confirmation e-mails tothe payor 110 and the payee 130 notifying them of completion of thetransaction. The routine 690 then returns in step 890.

Requesting Money from Other Individuals

FIG. 9 is a logical flow diagram 900 illustrating exemplary steps for arequest money process 900 in which a payee 130 can request money 180from a payor 110. The request money process 900 begins with step 910.

In step 910, the payee 130 logs into the payee's account through asecure connection with the payment enabler 170. The payee 130 thenselects the “request money” option, perhaps by clicking the “requestmoney” button 240.

In step 920, the payee 130 provides the payment enabler 170 withinformation used to process the money request: This may be done via aWeb page form. In step 930, the payment enabler 170 adds the transactionas a “request” type transaction to the pending transactions file of thepayee 130.

In step 940, the payment enabler 170 searches for the e-mail address ofthe payor 110 in the database of user accounts to determine if the payoris a registered user of the payment enabler 170. In step 945, thepayment enabler 170 determines if the address was found. If the addresswas not found, then the payor 110 does not have an account with thepayment enabler 170, and the “NO” branch is followed to step 950.

In step 950, the payment enabler 170 sends an e-mail to the payor 110notifying the payor of the money request. This e-mail also invites thepayor 110 to register for an account with the payment enabler 170.

In step 955, the payor 110 registers for an account with the paymentenabler 170. Preferably, the payor 110 reaches a registration page ofthe payment enabler 170 by following a link in the e-mail. Step 970, tobe discussed shortly, is then executed.

Referring again to step 945, if the payment enabler 170 found the e-mailaddress of the payor 110 in the database of user accounts, then thepayor does have an account with the payment enabler, and the “YES”branch is followed to step 960. In step 960, the payment enabler 170sends an e-mail to the payor 110 notifying the payor of the moneyrequest and containing a link to a Web page through which the payor canrespond to the money request. In step 965, the payor 110 follows thelink in the e-mail, and step 970 is then executed.

Step 970 follows either step 955 or step 965. In step 970, the paymentenabler 170 provides the payor 110 with a Web page for authorizingpayment of the amount 180 requested in the money request. If step 970 isreached from step 955, then the payment enabler 170 preferably providesthis Web page to the payor 110 automatically at the end of theregistration process.

In step 980, the payor 110 authorizes the payment 180. In step 990, thepayment enabler 170 completes the money transfer with an intermediary160 acting as a conduit between the payor 110 and the payee 130 in themanner already described. The payment enabler 170 also updates thepending and history transactions files for both the payor 110 and thepayee 130. The request money process 900 then ends in step 995.

FIG. 10 is a logical flow diagram 970 illustrating exemplary steps bywhich the payee 130 can provide the payment enabler 170 with theinformation used by the payment enabler to process the money request.The logical flow diagram of FIG. 10 corresponds to routine 920 on FIG.9. The routine 920 begins with step 1010.

In step 1010, the payee 130 specifies the e-mail address of the payor110. The payee 130 may do this by typing in the e-mail address or byselecting the e-mail address from an online e-mail address book such asthe one depicted in FIG. 4.

In step 1020, the payee 130 specifies the amount 180 to be requestedfrom the payor 110. In step 1030, the payee 130 specifies a subject thatmay identify the transaction in the pending and history transactionsfiles. This subject may also comprise the subject line of an e-mailnotifying the payor 110 of the money request.

In step 1040, the payee 130 optionally specifies a message for thepayment enabler 170 to include in the e-mail notifying the payor 110 ofthe money request. In step 1050, the payee 130 optionally selects amoney receipt method to be used in this transaction instead of thedefault money receipt method specified in the payee's profile. Theroutine 930 then returns in step 1060.

A number of variations and modifications of the invention can also beused. The payment capability could be used to pay subscription fees andother electronic costs. For example, the some music web sites chargesmall fees for downloading music or may charge a small monthly fee. Arequest could be made to the payor that is fulfilled by transferringfunds from the stored value account of the payor to the stored valueaccount of the merchant payee.

While the principles of the invention have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the invention.

1-63. (canceled)
 64. A method for transferring money using a wide-areacomputer network and a stored value account, the method comprising:creating the stored value account for a user on a server computersystem; receiving money in the stored value account; receiving inputfrom the user indicating a transfer method and trigger condition;determining if the trigger condition is satisfied; and automaticallytransferring credit from the stored value account of the user using thetransfer method if the trigger condition is satisfied.
 65. The methodfor transferring money using the computer network and the stored valueaccount as recited in claim 64, wherein determining step includes one ofthe following steps: determining a credit balance in the stored valueaccount exceeds a specified amount; and determining that a period oftime has expired.